폼 기반 로그인

폼 기반 로그인의 인증 과정은 사용자가 웹사이트나 애플리케이션에 접속하여 자신의 신원을 증명하는 일련의 단계를 말한다. 이 과정은 주로 클라이언트와 서버 간의 요청과 응답으로 이루어진다.

먼저, 사용자는 로그인 폼이 제공된 페이지에서 사용자명과 비밀번호를 입력하고 제출 버튼을 클릭한다. 이때 입력된 자격 증명은 클라이언트 측에서 수집되어 HTTP 요청을 통해 인증 서버로 전송된다. 전송 과정에서는 보안을 위해 HTTPS 프로토콜을 사용하는 것이 필수적이다.

서버는 전달받은 자격 증명을 데이터베이스에 저장된 정보와 비교하여 검증한다. 검증이 성공하면 서버는 사용자에게 고유한 세션 식별자를 생성하고, 이를 쿠키에 담아 클라이언트에게 응답으로 보낸다. 이후 사용자는 이 세션 쿠키를 통해 인증 상태를 유지하며 서비스에 접근할 수 있다. 만약 검증에 실패하면 서버는 로그인 실패 메시지를 반환하고, 사용자는 다시 자격 증명을 입력해야 한다.

이러한 인증 과정은 세션 관리와 밀접하게 연관되어 있으며, 인가를 위한 기초 단계를 제공한다. 과정의 각 단계마다 적절한 웹 보안 조치가 적용되지 않으면, 자격 증명 탈취나 세션 하이재킹과 같은 보안 위협에 노출될 수 있다.

세션 관리는 폼 기반 로그인 이후 사용자의 인증 상태를 유지하는 핵심 메커니즘이다. 사용자가 로그인에 성공하면, 서버는 해당 사용자를 식별할 수 있는 고유한 세션 식별자를 생성한다. 이 식별자는 일반적으로 쿠키를 통해 사용자의 브라우저에 저장되며, 이후 사용자가 웹사이트 내 다른 페이지를 요청할 때마다 이 쿠키가 서버로 전송되어 사용자를 인증된 상태로 식별한다. 서버는 이 식별자를 키로 하여 메모리나 데이터베이스에 사용자의 로그인 정보와 같은 세션 데이터를 저장한다.

효율적인 세션 관리를 위해서는 보안과 성능을 고려해야 한다. 세션 식별자는 예측 불가능하게 생성되어야 하며, HTTPS를 통해서만 전송되어 중간자 공격으로부터 보호받아야 한다. 또한 서버 측에서는 세션 데이터의 저장소를 적절히 관리하고, 일정 시간 동안 활동이 없으면 세션을 만료시키는 타임아웃 정책을 적용하는 것이 일반적이다. 이는 사용자가 로그아웃을 잊고 떠난 경우에도 세션이 무기한 유지되는 것을 방지한다.

세션 관리 방식은 애플리케이션의 아키텍처에 따라 달라질 수 있다. 전통적인 서버 측 렌더링 애플리케이션에서는 세션이 서버 측에서 완전히 제어되는 반면, 단일 페이지 애플리케이션과 같은 현대적 웹 애플리케이션에서는 RESTful API와 함께 사용될 때 JSON Web Token과 같은 토큰 기반 방식을 채택하기도 한다. 그러나 폼 기반 로그인의 전형적인 흐름에서는 서버 측 세션 저장소를 사용하는 방식이 여전히 널리 적용된다.

세션 관리의 취약점은 심각한 보안 위협으로 이어질 수 있다. 주요 위협으로는 세션 식별자를 탈취하는 세션 하이재킹과, 교차 사이트 요청 위조와 같은 공격이 있다. 따라서 개발자는 세션 쿠키에 Secure 및 HttpOnly 속성을 설정하고, 정기적인 세션 회전을 구현하며, 교차 사이트 요청 위조 방어 조치를 마련하는 등 철저한 보안 관행을 따라야 한다.

로그인 폼은 폼 기반 로그인의 핵심 구성 요소로, 사용자가 웹사이트나 애플리케이션에 접속하기 위해 자격 증명을 직접 입력하는 사용자 인터페이스이다. 일반적으로 HTML의 <form> 요소를 사용하여 구현되며, 사용자명 입력 필드, 비밀번호 입력 필드, 그리고 제출 버튼을 기본으로 포함한다. 이 폼은 사용자가 인증을 요청하는 첫 번째 접점이 된다.

로그인 폼의 주요 기능은 사용자가 입력한 아이디와 패스워드를 안전하게 인증 서버로 전송하는 것이다. 이 과정에서 폼은 POST 메서드를 사용하여 데이터를 전송하며, 민감한 정보인 비밀번호 필드는 type="password" 속성을 사용해 입력 내용이 가려지도록 설계된다. 또한, 폼은 접근성을 고려하여 각 입력 필드에 적절한 label 요소를 연결하고, 자동 완성 속성을 활용해 사용자 편의성을 높이는 경우가 많다.

보안 측면에서 로그인 폼은 HTTPS 프로토콜을 통해서만 서버와 통신해야 하며, 교차 사이트 요청 위조 공격을 방지하기 위해 CSRF 토큰을 포함하는 것이 필수적이다. 또한, 브루트 포스 공격을 억제하기 위해 캡차를 도입하거나 로그인 시도 횟수를 제한하는 기능을 추가하기도 한다. 이러한 보안 요소들은 폼의 안전성을 확보하는 데 중요한 역할을 한다.

로그인 폼의 디자인과 사용자 경험은 전환율에 직접적인 영향을 미친다. 입력 필드의 배치, 버튼의 명확성, 오류 메시지의 유용성 등은 사용자가 시스템에 쉽게 로그인할 수 있도록 돕는다. 최근에는 단일 페이지 애플리케이션의 발전으로, 페이지 전체를 새로 고치지 않고도 로그인 상태를 처리하는 비동기 방식의 폼 제출이 점차 보편화되고 있다.

폼 기반 로그인에서 사용자 인증 정보는 사용자가 자신의 신원을 증명하기 위해 시스템에 제공하는 데이터를 말한다. 가장 일반적인 형태는 사용자명과 비밀번호의 조합이다. 사용자명은 주로 이메일 주소나 시스템 내에서 고유하게 식별되는 아이디를 사용하며, 비밀번호는 사용자만이 알고 있어야 하는 비밀 값이다. 이 정보는 데이터베이스에 저장된 기존 기록과 비교하여 사용자를 인증하는 데 사용된다.

인증 정보는 서버 측에서 안전하게 저장되고 관리되어야 한다. 비밀번호는 암호화되지 않은 평문 형태로 저장해서는 안 되며, 솔트가 적용된 암호화 해시 함수를 통해 해시 값으로 변환하여 저장하는 것이 표준 관행이다. 이는 데이터베이스가 유출되더라도 원본 비밀번호를 복원하기 어렵게 만들어 보안성을 높인다. 일부 시스템은 이중 인증을 위해 휴대전화 번호나 보안 질문과 같은 추가 인증 요소를 요구하기도 한다.

사용자 인증 정보의 수명 주기 관리도 중요하다. 사용자는 일반적으로 회원가입 과정에서 최초의 인증 정보를 설정하며, 이후 비밀번호 찾기 기능을 통해 재설정할 수 있다. 보안을 강화하기 위해 시스템은 주기적인 비밀번호 변경을 권장하거나, 약한 비밀번호 사용을 방지하기 위한 비밀번호 정책을 적용한다.

인증 서버는 폼 기반 로그인 과정의 핵심 구성 요소로, 사용자가 제출한 자격 증명의 유효성을 검증하는 역할을 담당한다. 이 서버는 일반적으로 백엔드 애플리케이션의 일부로 운영되며, 데이터베이스에 안전하게 저장된 사용자 정보와 입력된 정보를 비교하여 인증을 수행한다. 인증 서버는 단순히 아이디와 비밀번호를 확인하는 것을 넘어, 암호화된 비밀번호를 해시하여 비교하거나, 다중 인증 요청을 처리하는 등 보안 로직을 실행하는 중추적인 기능을 한다.

인증 서버의 주요 작업은 클라이언트로부터 전송받은 사용자명과 비밀번호를 검증하는 것이다. 이를 위해 서버는 데이터베이스에서 해당 사용자명에 매칭되는 레코드를 조회한 후, 저장된 해시 값과 사용자가 입력한 비밀번호의 해시 값을 비교한다. 인증이 성공하면, 서버는 사용자의 세션을 생성하고 이를 식별할 수 있는 세션 ID나 토큰을 클라이언트에 발급한다. 이 토큰은 주로 쿠키에 담겨 반환되며, 이후 사용자의 요청을 인가하는 데 사용된다.

또한, 인증 서버는 보안 정책을 적용하는 중요한 지점이기도 하다. 예를 들어, 로그인 시도 실패 횟수를 제한하여 무차별 대입 공격을 방지하거나, 모든 인증 통신에 HTTPS를 강제할 수 있다. 소셜 로그인이나 OAuth와 같은 외부 인증 시스템을 통합하는 경우, 인증 서버는 해당 ID 공급자와의 연동을 처리하는 프록시 역할도 수행하게 된다.

폼 기반 로그인에서 패스워드 보안은 시스템의 전반적인 안전성을 결정하는 핵심 요소이다. 서버는 사용자가 제출한 평문 패스워드를 그대로 저장해서는 안 되며, 반드시 암호화된 형태로 저장해야 한다. 일반적으로 단방향 해시 함수를 사용하여 패스워드를 해시 값으로 변환한 후 이를 데이터베이스에 저장한다. 이때 단순한 해시 함수만으로는 충분하지 않으며, 무차별 대입 공격에 대비하기 위해 솔트라는 임의의 데이터를 패스워드에 추가하여 해시를 생성하는 것이 필수적이다. 또한, bcrypt나 Argon2와 같이 계산 비용이 높은 적응형 해시 함수를 사용하면 공격자의 브루트 포스 공격을 효과적으로 늦출 수 있다.

사용자 측면에서도 강력한 패스워드 정책이 적용되어야 한다. 시스템은 짧거나 흔히 사용되는 패스워드, 사용자명과 동일한 패스워드의 생성을 제한해야 한다. 최소 길이를 요구하고, 대문자, 소문자, 숫자, 특수문자를 조합하도록 유도하는 것이 일반적이다. 또한, 주기적인 패스워드 변경을 권장하거나, 중요한 서비스의 경우 다중 인증을 의무화하여 패스워드 단독 인증의 위험성을 보완한다. 사용자가 이전에 사용했던 패스워드를 재사용하지 못하도록 하는 정책도 유용하다.

패스워드 저장 및 처리 과정에서 발생할 수 있는 정보 유출 사고에 대비한 조치도 필요하다. 데이터베이스에 저장된 해시 값이 유출되더라도 원본 패스워드를 복원하기 어렵도록 해시 함수의 강도는 충분해야 한다. 관리자는 패스워드 관련 로그나 오류 메시지를 통해 패스워드 정보가 노출되지 않도록 주의해야 한다. 궁극적으로 패스워드 보안은 기술적 조치와 사용자 교육, 그리고 지속적인 보안 점검이 결합되어 완성된다.

폼 기반 로그인에서 HTTPS 사용은 전송 중인 인증 정보를 보호하기 위한 필수적인 보안 조치이다. 사용자가 입력한 아이디와 비밀번호와 같은 민감한 자격 증명은 HTTP 프로토콜을 통해 평문으로 전송될 경우, 네트워크 상에서 패킷 스니핑 공격에 노출되어 쉽게 탈취될 수 있다. HTTPS는 전송 계층 보안 프로토콜을 통해 클라이언트와 서버 간의 통신을 암호화하여, 이러한 중간자 공격을 방지한다.

HTTPS를 구현하기 위해서는 신뢰할 수 있는 인증 기관으로부터 SSL 인증서를 발급받아 웹 서버에 설치해야 한다. 이 인증서는 서버의 신원을 확인하고, 클라이언트와 서버가 안전하게 암호화 키를 교환할 수 있는 기반을 제공한다. 최신 브라우저들은 HTTPS가 적용되지 않은 페이지에서 비밀번호 필드를 사용할 경우 사용자에게 보안 경고를 표시하기도 한다.

폼 기반 로그인을 처리하는 모든 페이지, 특히 로그인 폼을 제공하는 페이지와 자격 증명을 제출받는 엔드포인트는 반드시 HTTPS를 통해 서비스되어야 한다. 또한, 인증 후 발급되는 세션 쿠키 역시 보안 속성을 설정하여 HTTPS 연결에서만 전송되도록 해야 한다. 이를 통해 쿠키 하이재킹 공격을 추가로 방어할 수 있다.

CSRF 방어는 폼 기반 로그인을 포함한 웹 애플리케이션에서 중요한 보안 요소이다. CSRF는 공격자가 피해자의 브라우저를 통해 권한이 필요한 요청을 위조하도록 유도하는 공격이다. 예를 들어, 사용자가 이미 로그인한 은행 사이트에서 공격자가 심어둔 링크를 클릭하면, 사용자의 브라우저는 저장된 세션 쿠키와 함께 자동으로 송금 요청을 보낼 수 있다. 이는 사용자의 의도와 무관하게 서버가 요청을 유효한 것으로 판단하게 만든다.

이를 방지하기 위한 가장 일반적인 방법은 CSRF 토큰을 사용하는 것이다. 서버는 사용자 세션마다 고유하고 예측 불가능한 토큰을 생성하여, 로그인 폼이나 다른 민감한 폼을 렌더링할 때 숨겨진 필드로 포함시킨다. 사용자가 폼을 제출하면 이 토큰 값도 함께 서버로 전송되며, 서버는 요청에 포함된 토큰이 세션에 저장된 값과 일치하는지 검증한다. 공격자는 정상적인 사용자의 세션에는 접근할 수 없으므로 유효한 토큰 값을 알지 못해 요청을 위조할 수 없다.

또 다른 방어 기법으로는 동일 출처 정책을 강화하는 방법이 있다. 중요한 요청에 대해 사용자 정의 HTTP 헤더를 요구하거나, 쿠키에 SameSite 속성을 설정하여 교차 사이트 요청을 제한할 수 있다. 특히 SameSite=Strict 또는 SameSite=Lax로 설정하면, 다른 사이트에서 발생한 요청에는 세션 쿠키가 전송되지 않아 CSRF 공격을 효과적으로 차단한다.

보안을 위한 다중 인증 요구나 중요한 작업 전 비밀번호 재입력 확인도 CSRF 공격에 대한 추가적인 보호 계층이 될 수 있다. 그러나 이러한 방법들은 사용자 경험에 영향을 줄 수 있으므로, CSRF 토큰과 같은 기술적 방어 수단을 기본으로 구현하는 것이 권장된다. 효과적인 CSRF 방어는 웹 보안의 핵심이며, OWASP에서도 상위 10대 웹 애플리케이션 보안 위협 중 하나로 지속적으로 분류하고 있다.

브루트 포스 방지는 폼 기반 로그인 시스템에서 가장 기본적이고 필수적인 보안 조치 중 하나이다. 이는 공격자가 자동화된 도구를 사용해 가능한 모든 아이디와 비밀번호 조합을 무차별적으로 시도하여 정당한 사용자의 계정에 침입하는 공격을 막기 위한 것이다.

가장 일반적인 방어 수단은 로그인 시도 실패 횟수를 제한하는 것이다. 특정 IP 주소나 사용자 계정에서 짧은 시간 내에 여러 번 로그인에 실패하면, 시스템은 일정 시간 동안 추가 로그인 시도를 차단하는 계정 잠금이나 IP 차단을 적용한다. 또한, CAPTCHA를 도입하여 로그인 폼 제출 시 인간 사용자인지 자동화된 봇인지를 확인하는 절차를 추가하는 방법도 널리 사용된다. 이를 통해 자동화된 공격 스크립트의 실행을 효과적으로 방해할 수 있다.

보다 진보된 접근 방식으로는 지연 응답이나 점진적 지연 기법이 있다. 이는 로그인 실패 횟수가 누적될수록 서버의 응답 시간을 인위적으로 지연시켜 공격자의 시도 속도를 극도로 떨어뜨리는 방법이다. 또한, 의심스러운 로그인 패턴, 예를 들어 지리적으로 멀리 떨어진 위치에서의 짧은 시간 내 연속 접속이나 알려진 악성 IP 주소 풀에서의 시도 등을 실시간으로 탐지하고 차단하는 위협 탐지 시스템을 연동하는 것도 효과적이다. 이러한 다층적인 방어 전략은 브루트 포스 공격으로부터 사용자 계정과 시스템을 보호하는 데 핵심적이다.

서버 측 렌더링 방식은 전통적인 웹 애플리케이션에서 폼 기반 로그인을 구현하는 일반적인 방법이다. 이 방식에서는 로그인 폼을 포함한 모든 HTML 페이지가 웹 서버에서 생성되어 사용자의 웹 브라우저로 전송된다. 사용자가 폼에 사용자명과 비밀번호를 입력하고 제출하면, 브라우저는 이 자격 증명을 서버로 전송한다. 서버는 이를 받아 데이터베이스에 저장된 정보와 비교하여 인증을 수행한 후, 인증 결과에 따라 새로운 HTML 페이지를 생성하여 응답으로 보낸다.

인증이 성공하면, 서버는 일반적으로 세션 식별자를 생성하여 쿠키에 저장하고, 이를 통해 사용자의 상태를 유지한다. 이후 사용자가 다른 페이지를 요청할 때마다 브라우저는 이 쿠키를 함께 전송하고, 서버는 세션 정보를 확인하여 사용자를 식별한다. 이 과정에서 모든 비즈니스 로직과 데이터 처리는 서버에서 이루어지며, 클라이언트는 주로 렌더링된 결과를 표시하는 역할만 담당한다.

이 방식의 주요 장점은 검색 엔진 최적화가 용이하고, 초기 페이지 로딩 속도가 비교적 빠르며, 자바스크립트가 비활성화된 환경에서도 기본 기능이 동작할 수 있다는 점이다. 또한 보안 측면에서 중요한 인증 로직이 서버에 집중되어 있어 클라이언트 측에 노출될 위험이 적다.

반면, 사용자가 폼을 제출할 때마다 전체 페이지를 새로고침해야 하므로 사용자 경험이 다소 떨어질 수 있다. 또한 서버에 매번 요청을 보내야 하므로 서버의 부하가 증가하고, 네트워크 지연에 더 민감할 수 있다는 단점이 있다. 이러한 특성으로 인해 실시간 상호작용이 많은 현대적 웹 애플리케이션보다는 비교적 정적인 콘텐츠를 제공하는 전통적인 웹사이트에 더 적합한 방식으로 평가된다.

단일 페이지 애플리케이션에서 폼 기반 로그인은 전통적인 서버 측 렌더링 방식과는 다른 구현 방식을 가진다. SPA는 초기 로딩 시 모든 필요한 자바스크립트와 HTML을 다운로드한 후, 사용자 상호작용에 따라 필요한 데이터만 서버와 비동기적으로 교환하며 페이지 전체를 새로 고침하지 않는다. 따라서 로그인 과정도 AJAX나 Fetch API를 통해 백엔드 서버로 자격 증명을 전송하고, JSON 형태의 응답을 받아 처리하는 방식으로 이루어진다.

인증 성공 시, 서버는 세션 ID 대신 JWT와 같은 토큰 기반 인증 방식을 사용하여 액세스 토큰을 발급하는 경우가 많다. 이 토큰은 클라이언트 측 자바스크립트에 의해 안전하게 저장되고, 이후 모든 API 요청의 HTTP 헤더에 포함되어 사용자의 인증 상태를 증명한다. 이 방식은 서버의 세션 저장 부하를 줄이고 확장성을 높이는 장점이 있다.

보안 측면에서는 몇 가지 특별한 고려가 필요하다. 토큰을 저장할 때는 XSS 공격으로부터 보호하기 위해 로컬 스토리지보다는 HttpOnly 쿠키를 사용하는 것이 권장된다. 또한, CSRF 방지를 위한 토큰을 폼에 포함시키거나, CORS 정책을 엄격하게 설정하여 인증된 요청만 특정 오리진에서 오도록 제한해야 한다. 클라이언트 사이드 렌더링 특성상 초기 로그인 페이지 자체도 보호되어야 하며, 인증되지 않은 사용자가 보호된 라우트에 접근하지 못하도록 라우터 수준에서의 접근 제어 구현이 필수적이다.

소셜 로그인은 사용자가 웹사이트나 애플리케이션에 가입하거나 로그인할 때, 구글, 페이스북, 트위터, 네이버, 카카오와 같은 외부 소셜 네트워크 서비스의 계정을 통해 인증을 대행받는 방식을 말한다. 이는 사용자가 직접 아이디와 비밀번호를 생성하고 입력해야 하는 전통적인 폼 기반 로그인의 대안으로 자리 잡았다.

소셜 로그인의 핵심은 OAuth나 OpenID Connect와 같은 표준 인증 및 인가 프로토콜을 활용하는 데 있다. 사용자는 서비스 제공자의 로그인 페이지로 리디렉션되어 자신의 자격 증명을 입력하고, 해당 서비스는 애플리케이션에 사용자의 신원 확인과 기본적인 프로필 정보(예: 이메일 주소, 이름)를 안전하게 전달한다. 이 과정에서 애플리케이션은 사용자의 소셜 미디어 비밀번호를 직접 받지 않아 보안 위험을 줄인다.

이 방식은 사용자에게 별도의 계정을 생성하고 기억할 부담을 덜어주는 편의성을 제공하며, 서비스 제공자에게는 회원 가입 장벽을 낮춰 사용자 유입을 촉진할 수 있다는 장점이 있다. 그러나 사용자의 개인정보가 소셜 미디어 플랫폼에 집중되고, 해당 플랫폼의 장애 시 로그인 서비스가 중단될 수 있으며, 제공받는 정보의 범위가 제한적일 수 있다는 점은 고려해야 할 사항이다.

OAuth는 사용자가 제3자 애플리케이션에 자신의 계정 정보(예: 구글 계정)를 직접 노출하지 않고도, 해당 애플리케이션이 사용자를 대신하여 리소스 서버에 접근할 수 있는 권한을 부여하는 인가 프레임워크이다. 주로 API 접근 권한을 위임하는 데 사용되며, 사용자는 인증 서버에서 직접 인증을 완료하고 애플리케이션에 액세스 토큰을 발급받는다. 이 과정에서 애플리케이션은 사용자의 비밀번호를 알지 못하며, 위임받은 범위 내에서만 사용자의 데이터에 접근할 수 있다.

OpenID Connect는 OAuth 2.0 프레임워크 위에 구축된 인증 계층으로, 단순한 인가를 넘어 사용자의 신원을 확인하는 표준화된 방법을 제공한다. OpenID Connect는 ID 토큰이라는 개념을 도입하여, 토큰 내에 사용자의 기본 프로필 정보(사용자 식별자, 이메일 등)를 포함시킨다. 이를 통해 클라이언트 애플리케이션은 사용자가 누구인지 안전하게 확인할 수 있으며, 사용자 인증 정보를 직접 관리하지 않고도 싱글 사인온과 같은 기능을 구현할 수 있다.

폼 기반 로그인과 비교할 때, 이 두 방식은 사용자가 새로운 사용자명과 비밀번호를 생성하고 기억할 필요가 없다는 공통된 장점을 지닌다. 대신 사용자는 이미 신뢰할 수 있는 인증 서버(예: 소셜 미디어 플랫폼, 대기업의 클라우드 서비스)에 등록된 자격 증명을 사용하여 다양한 서비스에 로그인할 수 있다. 이는 사용자의 편의성을 크게 높이고, 서비스 제공자에게는 사용자 등록 장벽을 낮추고 패스워드 보안 관리 부담을 줄여준다.

토큰 기반 인증은 폼 기반 로그인과 같은 전통적인 세션 관리 방식과 구분되는 현대적인 인증 방식이다. 이 방식은 사용자가 자격 증명(예: 아이디와 비밀번호)을 제출하여 최초 인증을 받은 후, 서버가 발급한 암호화된 문자열인 토큰을 이후의 모든 요청에 포함시켜 신원을 증명하는 방식으로 동작한다. 이 토큰은 일반적으로 JSON 웹 토큰과 같은 표준 형식을 가지며, 사용자의 신원 정보와 유효 기간 등을 담고 있다. 클라이언트는 이 토큰을 로컬에 저장했다가, API 호출 시 HTTP 헤더에 첨부하여 서버에 전송한다.

폼 기반 로그인이 서버 측에 세션 정보를 저장하고 관리하는 상태 유지 방식이라면, 토큰 기반 인증은 서버가 상태를 유지하지 않는 무상태 아키텍처에 적합하다. 서버는 토큰의 서명을 검증하고 내부 정보를 해석하여 사용자를 인증하므로, 매 요청마다 데이터베이스를 조회할 필요가 없어 확장성이 뛰어나다. 이는 특히 마이크로서비스 환경이나 모바일 애플리케이션, 단일 페이지 애플리케이션에서 널리 사용된다.

주요 구현 방식으로는 OAuth 2.0 프레임워크 내의 Bearer Token 사용이나 JWT가 대표적이다. 토큰 기반 인증을 사용하면 교차 출처 리소스 공유 정책 하에서도 여러 도메인에 걸쳐 인증 정보를 안전하게 전달할 수 있으며, 세션 하이재킹 위험을 줄일 수 있다는 장점이 있다. 그러나 토큰이 탈취당할 경우를 대비해 짧은 유효 기간 설정과 재발급 메커니즘, 토큰을 안전하게 저장하는 방법(예: HttpOnly 쿠키 사용) 등 보안 고려사항이 필요하다.